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(57) Abstract: The invention relates to management of the use of digital data. Especially the inven-tion relates to management of 
the use of various digital resources and services as well as data communication connections by means of licensing. In a method 
accord'ing to the invention, in order to license digital resources and services, as a response to a requested licensing request, in a 
license request unit (103) handling license templates containing attributes, transforming a license template into a license re-quest by 
changing and/or adding attribute values (41 1) of a license template, where after the license request is transmitted to a specific license 
creation unit (102) han-dling license requests. In the license creation unit (102) transforming the license re-quest to an execution 
license by changing and/or adding attribute values (506) of the license request, from where the execution license is transmitted to a 
license control unit (lOS) controlling the usage of resources and/or services. 
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A method and a system for licensing digital resources and services 



The invention is related to management of the use of digital data. Especially this in- 
vention is related to management of the use of various digital products, services and 
5 data communication conaections by means of licensing. 

Management of the use of digital data, service and data connections and resource is 
an essential part of an operational system In this application a resource refers to a 
physical operational unit or a system, tiiat can be such as computer equipment or 
-software, functionality implemented by software, a set of articles in a database or 
10 data communication capacity. Thus, the resource implements a certain service, that 
can be such as operation inq)lemented by hardware equipment or software, func- 
tionality of program or certain data communication capacity. Botii of these are thus 
managed by using licenses, which defme tiie rights to use the service inq)lemented 
by a certain resource. 

15 Publication US 5457746 presents a method and equipment, in which data pubhshed 
using various equipment is licensed. The publishing mean can be such as a CD- 
ROM (Compact Disk Read Only Memory), data contained in which is divided into 
sections, whose access is controlled. For charging tiiese data sections biUing op- 
tions, also known as attiibutes, can be used. Controlling access to information in a 

20 data section is based on encryption of information contained in data sections so that 
its decryption requires a data section specific key. The characteristic features of tiie 
method presented in the pubUcation are encryption of the data in the specific way, 
distiibution of the data witii certain mechanism and controlling tiie data usage witii 
the aid of an update metiiod. The presented metiiod is limited to a use of encrypted 

25 data sections. 

In publication WO 0054127 tiiere is presented a method and equipment for binding 
resources to an application. As a basic mechanism tiiere is used a public and a pri- 
vate key between two program modules. The invention is based on embedding the 
keys into software by means such tiiat, tiie public key is integrated into die applica- 
30 tion and tiie private key iato tiie resource. Also tiie metiiod and equipment for li- 
censing reusable program libraries presented in publication US 6188995 is based on 
keys. The use of tiiese reusable software libraries is controlled from the application 
program so tiiat a specific stiing grants die permission to tiifi usage of flie software 
library, if the user has the corresponding license key. 
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It is typical for the known solutions to produce a detailed licensing system for a 
specific purpose, when new solutions and properties require their own systems. In 
the prior art publications there is commonly used some kind of encryption method 
in between the system and the resources, eitiier keys or encryption of data for one 
5 section at a time. Controlling the Ucensing and the licensed services and resource is 
impractical and irritating for the users, due to which licensing is not used. 

The aim of the invention is to produce a hcensing system, which is extendable and 
modifiable. In addition, the aim of the invention is to diversify the properties and 
the use of the licenses so that accesses and functionality are easily and flexibly 
10 available and further extendable. 

The aim is reached by using license templates for controllable and flexible creation 
of hcenses. The Ucense templates can be defined to match the respective require- 
ments. In addition the hcense templates can be also modified later on, during the 
usage, and multiple templates with alternative scope can be used for a single re- 
15 source concurrently. 

The invention is characterized in that what is stated in the characterizmg part of the 
independent claims. Advantageous embodiments of the invention are described in 
dependent claims. 

The execution licenses used according to the present invention are created using li- 
20 cense templates. The hcense templates contain variables, attributes, the aid of which 
the service or resource to be licensed will be defined on the license template. Li- 
cense templates are transmitted to the hcense request unit, in which the attributes of 
the license template are used for defining the target environment of the hcensed ser- 
vice or resource and the Hcense template is transformed into a hcense request. The 
25 Ucense request will be handed over to a hcense creation unit, where, with the aid of 
attributes of the hcense request, constraints for the use of the licensable service or 
resource are defined, and the Ucense request is transformed into an execution U- 
cense. The execution Ucense is next transmitted to a Ucense control unit of the target 
environment, which controls the usage of the execution hcenses, verifies that the 
30 constraints and the identifiers are vaUd, and is able to interpret execution Ucenses 
flexibly. Creation of the hcenses can be centralized to a single site around a Ucense 
creation unit or constituted functions can be distributed into each target environment 
as integrated packages. Alternative arrangements are scrutinized later on. 
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Already existing licensed systems can be flexibly upgraded with new features, and 
the life cycle of a license can be managed by its attributes. Multiple parallel licenses 
can be granted for a single resource. In addition, licenses can easily be transmitted 
from equipment to another and be modified to be applicable into a system, some 
5 part of which will be changed. Because there exists a limited number of digital re- 
sources, they tolerate only a limited load. For example, a large number of concur- 
rent users can overload an e-conmierce site and bring the system down. According 
to an advantageous embodiment of the invention management of the digital re- 
sources is also ensuring the availabiUty of services. 

10 The end user will gain benefit from the Ucenses according to this invention by being 
able to get with them software and resources for trial use with low cost and later on 
it is easy to upgrade the Ucenses to full licenses. When needed, the user can also 
purchase extended continuation or features to the existing licenses. The hcensing is 
comfortable and almost transparent to the user. To the manufacturer the hcensing of 

15 the add-on products will clear up, because the manufacturer can control the use of 
the add-on products in addition to his core products. In addition, both manufacturers 
of the core product and the add-on product can simultaneously control the sales and 
use of certain licenses. 

Next the invention will be described in greater detail with the aid of accompanying 
20 drawings, in which 

Figure 1 illustrates a licensing system according to an advantageous embodiment 

of the present invention. 

Figure 2 illustrates as a flow chart the operation of a hcense control unit accord- 
ing to an advantageous embodiment of the present invention, 

25 Figure 3 illustrates an execution hcense according to an advantageous embodi- 
ment of the present invention, 

Figure 4 illustrates as a flow chart the operation of a hcense request unit accord- 
ing to an advantageous embodiment of the present invention. 

Figure 5 illustrates as a flow chart the operation of a hcense creation unit accord- 
30 ing to an advantageous embodiment of the present invention, 



Figure 6 



illustrates an arrangement for an electrical trading center according to 
an advantageous embodiment of the present invention, and 
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Figure 7 illustrates as a flow chart the operation of a resource roanagement sys- 
tem according to an advantageous embodiment of the present invention. 

Figure 1 illustrates a licensing system according to an advantageous embodiment of 
the present invention, in which Ucensing system all components can be located for a 
5 use of a set of computers using a specific www server or for a use of a LAN server 
and its cUents. According to another advantageous embodiment the components il- 
lustrated in figure 1 can be located in a single computer or in an UMTS, phone 
(Universal Mobile Telecommunications Services). The Ucensing system illustrated 
in figure 1 can also, according to an advantageous embodiment, be distributed into 

10 the execution environment, i.e. part of components can be connected to the target 
environment for example, via data communication connection. The target environ- 
ment includes aU the equipment and components, which conmiunicate with the li- 
cense control unit 104. License control unit 104 thus defines the target environment 
so that the target environment includes those components and equipment, which use 

15 the Ucense control unit La question in order to get a right to use some resource or 
service controlled by hcenses. In target environment there are at least an execution 
license, a license control unit and some software or resource. According to an ad- 
vantageous embodiment the hcense control unit 104 and the unit using the service 
(using unit) 105 have been integrated into a single uniform component. The integra- 

20 tion ensures uniform operation of the using unit 105 and die license control unit 
104, and it is not possible, for example, to implement a false Ucense control unit in 
between the components of the integrated system, which would accept every hcense 
to a specific target environment. 

If the using unit 105 is for example a LAN server's terminal, which wishes to open 
25 a known text processing program, for example MS Word text processing program 
registered by Microsoft, the terminal will request a permission to use this program 
firom the Ucense control unit 104. The Ucense control unit 104 searches for the U- 
cense of the program to be started for example from a database, in which a Ucense 
registry is maintained. This data structure can be located in the central memory or 
30 mass storage 108 of the using unit 105. If the Ucense control unit 104 finds a vaUd 
Ucense for the resource in question and recognizes the requesting terminal, the U- 
cense control unit 104 wiU grant a permission to start the program in the terminal 
after checking first that the conditions of the Ucense are fulfilled. The Ucense con- 
tains attributes, whose values define, for example, the vaUd execution environment 
35 of the Ucense. The Ucense attributes wiU be scrutinized more closely with figure 3. 
The using unit 105 can also according to an advantageous embodiment request a to- 
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tally new license. In this embodiment the license control unit 104 and the license 
request unit 103 are situated advantageously in the same equipment or in the same 
server as the using unit 105. The using unit 105 thus wants to use a new resource or 
service and request a license from the license request unit 103. 

5 A license template is handed over to the license request unit 103 with the request 
The license template identlFies the service or resource requested. The license tem- 
plates are typically application-specific i.e. for each service or product to be li- 
censed there typically exists a specific Ucense template. According to an advanta- 
geous embodiment of the invention Ucense templates are produced in a Ucense tem- 

10 plate unit 101. The Ucense templates can be produced also by other methods knovra 
as such and those can be brought to the use of a Ucensing system according to an 
advantageous embodiment of the invention for example via data communication 
connection or a physical memory device, such as a floppy disk or a CD-ROM or the 
Ucense templates can be retrieved from network from a server. I.e/, the resource or 

15 service to be licensed is defined in the Ucense template. The manufacturer typicaUy 
controls and produces these Ucense templates. Whereas execution Ucenses are con- 
troUed and produced by the manufacturer or (re-) seUer of the product or s^ce. 
For example a Ucense template can define, that the product to be Ucensed is a text 
processing program and the production and availabiUty of the Ucense templates can 

20 be arranged by the party selUng the Ucensed rights to use. 

The target environment of the requested Ucense is defined into the Ucense template 
in the Ucense request unit 103, for example by defining the terminal, in which this 
Ucense is requested to be used. In addition, the Ucense template is transformed into 
a Ucense request. A Ucense template and a Ucense request are states of the Ucense, 
25 phases of its Ufe-cycle, that are defined in the Ucense like other variables: by chang- 
ing attributes of the Ucense. 

From the Ucense request xmit 103 the Ucense request are transmitted to the Ucense 
creation unit 102 either via a data conununication connection, via shared memory, 
or using some similar mechanism or memory device, such as a floppy disk or alike. 

30 Advantageously the Ucense creation unit 102 uses the sarae memory unit 107 as the 
Ucense template unit 101. This way the Ucense creation unit 102 is able to access 
the Ucense template defining a resource or a service directiy from the memory unit 
107, where to for example the Ucense template unit 101 has stored it. The Ucense 
creation unit 102 can attach Ucense templates to the execution Ucense it produced, 

35 so that those are deUvered with the execution license to a user or to a using appUca- 
tion. For example a short-term trial Ucense can be attached with a Ucense template 
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for a long-term execution license, thus enabling the user after experimenting the 
product with the trial Ucense easily order an execution license. 

The hcense creation unit 102 maintains bookkeeping of Ucenses and assigns spe- 
cific constraints to the licenses, typical of which are such as duration of the license 
5 and the number of concurrent users. In addition, the license creation unit 102 
changes the state of the license from license request to execution license by chang- 
ing the attribute values of the license request. In the case mentioned as an example, 
when the product to be Ucensed is a word processing program, the target environ- 
ment of the license can be defined to be for example an individual computer or a 
10 network server, where upon the license can be used by a terminal equipment of the 
network. Advantageously the license creation unit 102 is located in equipment of a 
party selling rights to use the product. 

The execution Ucense produced by the hcense creation unit 102 and the license 
templates possibly attached to it are deUvered using a data communication connec- 

15 tion or a physical portable memory device into the target environment, in which the 
execution license is requested to be used and which has been defined in the execu- 
tion license. In the target environment the execution hcense will be installed by us- 
ing a set-up program into a file, registry or some similar data structure located in the 
mass storage 108. The mass storage 108 stores for example programs and other in- 

20 formation needed in hcensing. Typically the system has also central memory, in 
which a run-time version of the license is preferably stored. The central memory is 
preferably a part of the unit 105 using a resom'ce or a service Ucensed, and it is not 
separately described in figure 1 . 

In a single physical network there can co-exist multiple Ucense control units 104 
25 and target environments defined by the Ucense control units 104. For example one 
target envuronment can consist of the network and terminals defined by the Ucense 
control unit 104, in such a way, that the Ucense of a word processing program is lo- 
cated on a server, where from a number - defined in the Ucense - of network termi- 
nals can execute it concurrentiy with the permission of the Ucense control unit 104. 
30 The Ucense control unit 104 it thus monitoring the permitted use of the Ucenses. 
. The Ucense control unit 104 interprets execution licenses very flexibly, which 
means that, in execution Ucenses managed by a specific Ucense control unit 104 the 
number of attributes may vary or the right to use a specific resource or service can 
be granted based on execution Ucenses, which have different number or dissimilar 
35 attributes. In addition, the attributes can have multiple values or a single Ucense 
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control unit 104 can interpret execution licenses of multiple separate resource or 



service. 



In a network another additional license control unit can be installed to the same 
computer for example for a Ucensed service, to be used only in that computer, 

5 which can be such as a bookkeeping and accounting program. Permission from the 
license control unit 104 is needed for use of a licensed resource 106. The used re- 
sources 106 are located typically in the target environment, but they can also be lo- 
cated beyond a communication link. Advantageously also the hcense request unit 
103 is located in the target environment or at least the parts of it necessary for iden- 

10 tificadon of the target environment. 

According to another advantageous embodiment the components necessary for the 
Ucensing system can be located in a single equipment, for example m an UMTS 
phone, which thus in this case is the target environment. I.e., in the target environ- 
ment there are the using unit, the Ucense request unit 103, the license creation unit 

15 102 and the license control unit 104 and the necessary memory units 107,108. In 
this case the Ucense creation unit 102 can create a connection to a payment system, 
for example into a charged service number or to a similar charged direct debit sys- 
tem. The user must pay the fee before die execution license he requested can be cre- 
ated. After the payment the license creation unit 102 can, for example, produce an 

20 execution Ucense for a translation program so that the right of use is vaUd for a half 
an hour. This way the user gains access to a specific product or service for the time 
requested as a response to the pre-payment. According to another advantageous 
embodiment similar services or resources can be used as agreed either as a response 
to a monthly fee or so that the active time of use is charged. 

25 Figure 2 iUustrates as a flow chart operation of a Ucense control unit according to an 
advantageous embodiment of the present invention. In the initial state 201 the U- 
cense control unit is ready for action. In block 202 the Ucenses located in a specific 
or even in multiple memory units are read and the Ucenses are decrypted, if encryp- 
tion has been used. After this the check sums 203 of the Ucenses are calculated with 

30 some method known as such. By check sum 203 the integrity of the Ucenses is en- 
sured. In addition, in this block 203 the conditions and constiraints of the Ucense, 
such as the vaUdity period and identifiers of the target environment, wiU be vaU- 
dated at the time being in die target environment of this Ucense control unit 

In block 204 a service request or a new Ucense is received. A new Ucense 205 is re- 
35 ceived, when a user, an appUcation, or equipment wants to use some new service 
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and/or resource and the use requires licensing the service and/or resource. When the 
license control unit receives a service request 205, the requesting party wants to use 
some existing license. The service request will be received when the Ucense control 
unit is requested a permission for executing a licensed service or resource. In case 
5 of a new hcense 205, the control moves to the block 202, where after the attributes 
of the new license will be inspected to verify at least, that the licensing period is 
valid and in the target environment in question. In addition, the possible encryption 
of the Ucense is decrypted. If the received message is a service request 205, the con- 
trol moves to the block 206, in which the license control functionahty will be acti- 

10 vated. The service request will be received and the license control functionality wiU 
be activated when a user or a system wants to use a specific resource or service, for 
example when flie user wants to start a word processing program with an license at 
his device, which is coimected to a specific local network. Other similar resource or 
service can be such as launching some system; I/O functions of a system, such as 

15 opening, reading, changing, or otherwise handling files, databases, or parts of them; 
reservation or use of data communication capacity from a specific data communica- 
tion resource; initiating a specijSc fiinctibn or functionality; establishing a new ses- 
sion or a work-space; or logging in a new concurrent user. Activating a specific ser- 
vice can include parameters describing its usage, such as the location of the target, 

20 the volume or intensity of use, that are identified in Ucense' s attributes, so that they 
can be utilized in controlling the Ucenses. The license control unit can be activated 
in several separate ways, for example a system can activate the Ucense control unit 
by sending to it a signaling message either prior to use of a resource, while monitor- 
ing its own operation, periodically or randomly; or hardware or software of system 

25 platform can activate the Ucense control unit by signaling; or the license control unit 
can monitor signals of the system platform, such as operating system's messages, 
interrupt signals or messages of a data communication software, and activate itself 
when defined conditions are met. 

.» 

Signals of the system platform, that can be monitored and whose occurrence will 
30 initiate the Ucense vaUdation described above, include for example, conamon ser- 
vices of the target environment, such as remote procedure call, for example DCOM 
(Distributed Component Object Model), a service request, for example ORB (Ob- 
ject Request Broker), Microsoft Windows message, paging request of an operating 
system, service request of the file system, or other similar mechanism that is inde- 
35 pendent from the using system. 
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When the hcense control unit has been activated for the use of a specific resource or 
a service, it will also check in block 206, which licenses are valid for tiie resource or 
service in question. Conditions of the valid licenses are presented in Hcense's at- 
tributes. Different licenses and their contents will be scrutinized later in this apphca- 

5 tion with the figure 3. If the hcense was found and the conditions and possible con- 
straints defined in license's attributes are fulfilled 207, necessary bookkeeping tasks 
will be performed and the service request will be executed in block 208, i.e. access 
to the requested resource or service is provided. With the bookkeeping tasks we 
mean for example that infonnation about the current status of the license, number of 

10 its users and duration of the usage are stored into the registry maintaining hcense in- 
formation. What kind of information is stored at each times, depends on properties 
of the hcense and the hcense conti:ol unit. After this the execution moves to the 
block 204. If no valid hcense is found in the block 207, instiiictions for exception 
handling will be searched 209 for a resource or a service in question. If instiuctions 

15 for the exception 209 were found, tiie unit defined by flie instructions for exception 
handling, which can be, for example, the Ucense control unit or a specific program 
of the system, executes flie operations defined by tiie instiixctions for exception han- 
dhng 211. If instiuctions for exception handhng are not found 209, pre-defined de- 
fault operations 210 are executed. After executing these default operations 210 or 

20 exception handling operations ;21 1 the execution moves to the receive block 204. 

The insti^ictions for exception handhng define pohcies i.e. alternative actions to be 
taken in the target environment when tiie conditions defmed by tiie hcense's attrib- 
utes are not fulfilled or tiie Ucense is not integrity or some otiier expectable possible 
exception is observed. Instructions for exception handling defme, thus, how to pro- 

25 ceed, when the Ucense conttol unit observes problems. The perceived problem can 
be such that hcense's ending condition, for example time, has been reached or the 
Ucense has too much users or load. Some times no Ucense will be found for a ser- 
vice or the check-sum does not match. In tiie perceived exception the exception 
handhng operations to be carried out can be such tiiat tiie operation is interrupted, 

30 when the requested service wiU not be started, and no access to the resource will be 
provided. In some cases the exception is simply reported to the user or to the vendor 
of the resource and the operation is continued, for example in according to an old or 
a trial Ucense. Reports on exception can also be done periodically or tiie reports can 
be directed to a log and the service request in hand can be bypassed. In some cases 

35 the resource to be used is deleted from the target envkonment. Often tiie user is 
provided a possibihty to order a new Ucense or to continue operation in the re- 
stricted trial mode. 
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The possible exceptions and the exception handling operations to be taken follow- 
ing them are defined in the so-called license schema, based on which the hcense 
templates are produced. Specific exception handhng codes, which can be used in 
the Ucenses controlled by this hcense control unit, are transmitted to the Ucense 
5 control unit. These exceptions handling codes can be for example procedure calls. 
Then for possible exceptions there are defined exception handling codes to each li- 
cense, and the exception handling codes to be appUed when the exceptions appear. 
Thus, the hcense control unit has a set of pre-defined exception handling codes, out 
of which the ones to be used are chosen product-specific. As examples there can be 

10 mentioned some typical exceptions and possible exception handhng instructions for 
those: When the period of the execution license is over i.e. the Ucense has outdated, 
the situation is reported to the user and a temporary Ucense is taken to use or the 
execution is terminated- When the Umit of concurrent users is exceeded i.e. the U- 
cense has too many users, the last service request is by-passed and the situation will 

15 be reported to target environment logs and/or to the vendor of the resource. If a de- 
fined capacity constraint is exceeded i.e. there is an overload situation, the situation 
is reported to the user and the service request wiU be by-passed. If there is an at- 
tempt to start a service, to which there is no license, the execution will be stopped 
and the user can, for example, be offered a trial Ucense to that service. Unauthorized 

20 use, when the check-sum is invalid or a decryption fails, is typically reported to the 
vendor of a resource or a service. 

In figure 3 there is an execution Ucense according to an advantageous embodiment 
of the present invention, which comprises a header 310, a body 320 and a check- 
sum 330. In the header 310 of the execution Ucense there is a version number 31 1 of 

25 the Ucense schema used by the Ucensing system and possibly some additional data 
312, such as disposable key data used for encryption and decryption or seed data of 
a key generator. The data contained in the Ucense can be encrypted for example 
with some pubUc key, by using changing data of the Ucense to form a key or by en- 
coding the data with numbers or symbols or by replacing the characters with some 

30 others. The Ucense schema defines the set of the attributes, which can be used in a 
Ucense template. The Ucense schema is thus a kind of basic structure of the Ucense 
template, out of which the Ucense template itself wiU be modified. A Ucense schema 
can be, for example, as foUows: 



Schema 


1.1 


Product code 


Text 
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CPUID 


Intl2 


Start time 


Date 


End time 


Date 


Concuirent users 


Int4 



There is a version nvimber in the first row of the license schema. This number is the 
same for all Ucense templates, which have been created based on this version of the 
license schema. The same Ucense schema version number exists also in such a li- 

5 cense template, in which only a part of the definitions of the license schema are in 
use. For example using the license schema presented above we can create a Ucense 
template of the specific word processing program for a single user, in which case 
the number of concurrent users in the bottom is not needed at all. The version num- 
ber of the license schema is also in this kind of Ucense template 1.1. If into the U- 

10 cense template there needs to be defined a new variable (i.e. attribute), for example 
duration of the session, the version number of the Ucense schema will be changed. 
Even in this case not all of the data in the Ucense schema has to be defined. It is de- 
fined in the heuristics of the license control unit, which data of the Ucense schema at 
least has to be defined. Typically compulsory variables of a Ucense schema are 

15 product code, identifier of a target environment and duration of a Ucense. In the 
preceding presented Ucense schema the product code is represented m a textual 
fonnat and it can be, for example, "MS Word" registered by Microsoft, as a target 
environment identifier there is a processor identibBer (CPUID), which is represented 
as a 12-digit integer and start and end times of Ucense usage are represented in the 

20 preceding Ucense schema in date format. Times can naturally be represented also in 
time format. 

The execution Ucense contains always the body 320 with a group of attributes, 
which each have a single or multiple values, which describe information necessary 
for Ucensing. Examples of this information have been Usted next with references to 
25 numbers in figure 3. The body 320 typically contams identification information, 
such as an identifier of the product, an identifier of an execution Ucense and instruc- 
tions for exception handUng, which defme, what to do in various exception situa- 
tions. Figure 3 illustrates as an identifier of a target environment an identifier of a 
processor 321. Similar identifier binding a Ucense to a target environment can be an 
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identifier of a network card, a hard disk, a data commujoication connection or a 
similar component. These identifiers define one or more equipment or processor as 
a target environment, in which the license can be used. In addition, in the body 320 
there is product information, for example information about which resource, service 
5 or function is Ucensed with this execution Ucense, Such product information can be, 
for example, a product number or a name of a product. There can also be more than 
one value in a value hst of an attribute, such as a hst of identifiers of licensed sub- 
resources, that can be, for example, parts of a data base or specific services, or a hst 
of such license template identifiers, that are typically next offered for the user. In 

10 body 320 there is, in addition, information about the constraints of the use of the h- 
cense 322, such as how long or until when the license is vaUd or how many service 
requests are accepted. Further, in the body 320 there are instructions for exceptional 
situations (i.e. violation policies) 323. These instructions determine, what to do for 
example in cases where there is an attempt to execute the Ucense in a wrong target 

15 environment, the validity period of the license runs out, the number of allowed con- 
current users is exceeded or the data structure of the Ucense is found to be inconsis- 
tent. 

The hcense can also contain an attribute controlling the integrity of tiie Ucense, i.e. a 
check-sum or some similar figure 330 appUcable for integrity checking. Integrity of 

20 Ucense' s attributes and their values can be controlled with specific integrity instruc- 
tions. These instructions define interrelationships in between the attributes and their 
values, which an external party cannot deduce only by inspecting the Ucense. Cryp- 
tographic methods for checking the integrity and the origin of a digital message by 
using various check-sums and digital signatures are known as such and those can be 

25 used also as a part of the present invention especiaUy for ensuring the integrity of 
the data in the body. 

In addition to the elements represented in figure 3 the Ucense can contain informa- 
tion about the present status of the Ucense, for example, in which stage of the life- 
cycle the Ucense is. For example a Ucense can be obsolete or removed after the use, 

30 which corresponds to a so-caUed final state of a Ucense. A Ucense can stiU contain 
information about the Ucensing process. Based on this information there can be rea- 
soned for example, which Ucense templates should be offered next to the owner of 
this Ucense. A Ucense template contains also data about continuation Ucenses. 
Along with a Ucense request, information about possible continuation Ucenses is 

35 passed to the Ucense creation imit, which wiU deUver the necessary continuation U- 
cense templates along with the execution Ucense into the target enviromnent. 
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In addition to the execution Ucense represented in figure 3 there exists transfer U- 
censes, which are needed, when the target environment - or a part of it, such as the 
target computer - needs to be changed. An existing execution license can be trans- 
ferred from one execution environment to another by usmg a transfer Ucense for ex- 

5 ample, in cases, when equipment of a target environment will be changed so that the 
identifier of the target environment of the old Ucense 321 is no longer vaUd in die 
new equipment. K for example, in the case in figure 3 a processor, which has been 
defined vdth the target enviromnent identifier 321, will be replaced with a new one, 
the Ucense wiU not be vaUd in a new environment. A transfer Ucense is produced by 

10 a Ucense request unit, whose operation wiU be scrutinized in greater detail with fig- 
ure 4 later m this appUcation. A transfer Ucense wiU be produced roughly as fol- 
lows: tiie Ucense request unit converts an existing execution Ucense mto a tempo- 
rary execution Ucense. The temporary execution Ucense wiU be functional for a Um- 
ited period of time m its original target environment. In addition, die Ucense request 

15 unit wiU produce a tiransfer Ucense, which is a special Ucense template, mto which 
die attributes of tiie original execution Ucense have been copied. The Ucense request 
unit wiU form a Ucense request, which contains relevant attiibute knowledge of both 
the new, requested Ucense and the old execution Ucense via die transfer Ucense. The 
Ucense request wiU be processed in general in die same way as odier Ucense re- 

20 quests, which are scrutinized later in tiiis appUcation. 

A trial Ucense (or a demonstration Ucense) is yet anotiier commonly used form of a 
Ucense. The trial Ucenses provide a Umited functionaUty or duration. AU Ucenses 
foUow die oudme of die stiructure represented in figure 3. Typically diere are differ- 
ences m die state attributes of diEferent kinds of Ucenses and different number of at- 
25 tribute values may be fiUed in diem. In some cases new attributes can be added to 
the Ucenses. 

New Ucense templates are created for example, in a specific Ucense template unit 
based on a specific Ucense schema. The Ucense template unit is advantageously us- 
ing die same mass storage as the Ucense creation unit, in order to keep die informa- 

30 tion exchange m between diem as flexible as possible. The used Ucense schema de- 
fines die attributes used in Ucenses 321, 322, 323 and possibly also diek value do- 
mains. Adding a new atdibute to a Ucense schema wiU cause a change to a Ucense 
schema version number 311. The version number 311 wiU be changed into a Ucense 
template only if it is necessary, which is, only if die Ucense template uses attributes 

35 missing or changed firom an older schema. The Ucense schema version number 311, 
is in a header 310 of Ucense templates, and tiius also in Ucense requests and execu- 
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tion licenses. From a version number 311a license control unit gets the schema ver- 
sion, which it must be able to interpret in order to interpret the data of the execution 
license correctly (for example, the block 206 in figure 2). If the license control unit 
is not able to interpret the version number 311, for example, because it is so new, 
5 the license control unit acts according to the exception handling instructions ad- 
dressed to it (figure 2, block 211). In the instructions for exception handling there 
usually exists specific instructions to such exceptions, in which the version number 
311 is not recognized, i.e. a violation poUcy for unrecognized schema version. In 
this case the instruction for exception handling can, for example, define, that the li- 
10 cense control unit should order a newer version of the license control unit via data 
communication connection, inform the user and suspend execution or execute the 
hcense only in a mode of restricted use and inform the user about this. The opera- 
tion wiU follow the instruction for exception handling defined in the hcense tem- 
plate, which is copied into an execution license. An implementation of the instruc- 
15 tion for exception handling is programmed into a license control unit, and if it is 
missing a default procedure is followed. According to an advantageous embodiment 
the hcense request unit notices, situations, in which the hcense control unit is not 
able to recognize an execution hcense following a hcense request or a hcense tem- 
plate. The hcense request unit can react to this for example, by ordering a new ver- 
20 sion of a hcense control unit, by preventing creation of a license request or by in- 
forming the hcense creation unit. 

The Hcense templates are similar as the execution license represented in figure 3, 
only some of the attribute values are missing. Typically the attribute values binding 
the execution hcense to the target enviromnent and limiting the vahdity of the h- 
cense are naissing from the hcense templates. The hcense templates are typically 
stored in the mass storage of the system or in central memory. Alternatively tempo- 
rary hcense templates can be accessed via a data communication connection. The h- 
censing system accesses hcense templates typically through Intemet services. For 
example, new hcense templates and continuation hcense templates can be loaded 
from the net. Continuation hcense templates include for example own template of a 
temporal execution hcense for a following period of use, a hcense template for 
permanent use and a hcense template providing an additional feature. Along with a 
resource or a service it is possible to deliver hcense templates for a permanent h- 
cense and for a temporal hcense. In addition for trial use it is possible to dehver also 
trial hcenses, which are execution hcenses with limited vahdity period. The attrib- 
ute defining the last vahdity date of a trial hcense is typically set while setting up 
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tixe resource, whose usage it will control. TMs means, that after the first mstallation 
of a product its Ucense will be valid for a specific, pre-defined time penod. 

The figure 4 scrutinizes operation of a license request unit as a flow chart First data 
of Uce^es already existing in a target enviro^t is read 401. After thrs « 
of the execution licenses and fulfillment of the license conditions are mspected 402. 
Next information about the existing Hcenses is presented to the user and new prod- 
ucts are offered 403. THe Ucense request unit has some kind of user mterf ace for the 
user or a corresponding software interface to apphcations. through which the h- 
censes are presented. In this block 403 a list of all execution, tnal. transfer, and ob- 
solete hcenses read in block 401 as well as a Ust of Ucense templates are presented 
to the user. 

In the block 404 the user can order a new hcense. If the user does not want to order 
a new hcense 404, he can choose in the block 405. that he stops the — n 406 
or he may resume the execution, where after the control moves to the block 403. If 

5 the user orders a new Ucense 404. the information of a chosen Ucense template is 
represented to him in the block 407. The Ucense template information has been col- 
lected from attributes defined by the Ucense schema and/or firom separate data. The 
Ucense template is appUcation-specific and defines the product to be hcensed ^ 
addition it is possible, for example, to Unk descriptive data to ^^^^'^ ^^''^ 

20 using identifiers, which can be in textual or hypertext format. In the block 408 it ^ 
confLed from the user, whetiier die chosen Ucense is ordered. If die user cancels 
the order, the execution of the program moves into the block 403. If die hcense or- 
der is confirmed, the program verifies, that it has sufficient information for the de- 
Uvery and invoicing of the order 409. If not aU customer or payment data exist, the 

25 user is requested to complete die missing data 410. 

The Ucense request unit fiUs. in die block 411. die attribute values needed for die li- 
cense template, such as identifier of die target enviromnent and <=hauges 
from a Ucense template to a Ucense request. In die block 412 a possible check-s^ 
is calculated and when necessary die Ucense request is encrypted. Next, die e^s- 

30 tence of a data commmiication comiection. such as a TCP/IP transmission Control 
Protocol / Internet Protocol). RPC (Remote Procedure Call) or a shared memory lo- 
cation, to die Ucense creation unit is checked 413. If a data communication comiec- 
tion camiot be estabUshed. die Ucense request can be deUvered for exary le on a 
diskette to die Ucense creation unit and die user wiU be given instructions for dehv- 

35 ery 415 If a data communication Unk can be estabUshed. die Ucense request wdl be 
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sent or handed over through the data communication link to the license creation unit 
414. 

The requested hcense request wiU be delivered to the license creation unit, whose 
operation is described in the flow chart 5. The hcense creation unit receives the U- 

5 cense request, reads it 501 and decrypts a possible encryption. Next the integrity of 
the received license request will be checked with the aid of the check suin as well as 
the appUcability of the attributes and payment and order information 502. In the 
block 503 the invoicing transaction necessary for the requested license is performed 
for example through a network using some existing payment system or by passing 

10 invoicing information forwards for manual invoicing. In the block 504 there occurs 
a check, whether all the actions taken so far have been successful. If some previous 
action has failed, the problem is reported to the user 505 and execution of the pro- 
gram will be stopped 513. If the handling has worked out without problems, the 
execution will move to the block 506, in which the system completes and changes 

15 values of specific attributes of the hcense request. In this phase for example the end 
time of the hcense will be added as an attribute and the state will be changed from 
the state hcense request to the state execution hcense. Next possible check-sums are 
produced to the execution hcense and if needed, the data will be.encrypted 507. 

Bookkeeping data of Ucenses is recorded to a hcense database 508, which contains 
20 information of all hcenses. In the block 509 the execution hcense is further attached 
with templates of products of interest from the viewpoint of the execution hcense 
user and descriptions of the products, after which they are available for the hcense 
request unit (presented in figure 4). If a data conmiimication connection exists or 
can be established in between the hcense creation unit and the target environment 
25 510, the hcense creation unit sends the executions hcenses, attached hcense tem- 
plates and their descriptive information through the data communication connection 
to the hcense control imit located in the target environment. In the target environ- 
ment the execution hcenses are typicaUy stored into the mass storage or in a short- 
term use into the central memory used by the hcense control unit (presented in fig- 
30 ure 2). If a data communication connection cannot be estabhshed 510, instructions 
wiU be given 511 for dehvering the hcense information manually, for example us- 
ing a diskette or a CD-ROM disk. When the execution hcense has been dehvered 
512 or instructions for dehvering it have been given 511, the execution of the pro- 
gram is stopped 513. 

35 It is possible to locate a hcense creation unit even to multiple locations. The advan- 
tageous embodiment described in previous with figure 5 is a typical solution, in 
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ment the Uceme creation umt >s localea in me s ., ^.^jj,, k, this other ad- 
; U«.e control nnit Operation o( ^^^Z7^^-^ ^ 

previous in figure 5 otherwise, but now vv oavnient transac- 

abie to verify me data of to P^'T'-JfT "^TXlsnrnes tot 

r ."ir— . Ucense creaaon nnit 

there exists a data commumuauu Hr>*»c have the opportunity, 

A- tr. tKic Other advantageous embodiment does nave mc upp j 
^^rr^ab tvl^. data communication com^ection. to update 

TlntoTZl data^L 508. Thus according to Ms other advantag^us 
mformauon to the hcense oaia transmitted via a data 

embodiment, Ucenses and us^e -^-^^^^^^^ ,,,t descrip- 

communication connection, ^^^n possib^^^ ^^c^ J execution Ucense are 
tions 509 and Ucense ^^^itol^^t^olection and they are stoi.d to die 

retrieved ^^^^J^^^^^ ^or example into Oie mass storage 

target envu:omnent for a sufficient pen ^^^^^ 

or for a session to central ^--^f ^ 'X other advantageous em- 
can be taken to use in the begmmng of each ^^^f^^^^^^^^ , portable 
bodiment is useM for example, in 
equipment and charging is taken care of for example, Dy 
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load ucense templates and product data of new products to ^ ^.^ 
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their tnal hcenses irom me a 

tronic trading center can distnbute free tnal hcense^, ^J^^ 
tend by buying more resources, duration or sessions. A customer uses ^ 
lln^oL ^ding center and a licensing f -^^^^J^h- 
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L rer«Ld for trial use. a version wi^ less « or a sponsored ver- 
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sion with advertisements. The product, which can be a software or some other re- 
source, will typically be delivered using a data conmmnication connection, but it 
can alternatively be delivered, for example, on a CD-ROM or on a DVD (digital 
versatile disk). The product delivery comprises advantageously the software or 
5 other resource, a trial license providing hmited functionality, and a license template 
for the use of the chargeable product itself. In addition the delivery can comprise a 
license control unit, a Ucense request unit, and a user interface needed for licensing, 
unless these are implemented on a trading center. 

When the customer decides to order a product, the order will be made using the li- 
10 cense request unit. The Ucense request unit will produce a license request, which is 
delivered via an established data commimication connection to the electronic trad- 
ing center. License creation unit integrated to the trading center creates an execution 
license from the license request and takes care of the payment transactions with a 
method known as such. The execution license and license templates attached to it 
15 will be delivered back to the customer for the use of the product as well as for 
ordering other products, their licenses, and continuation hcenses. New Ucense tem- 
plates can be deUvered to the customers either directly or the customers can retrieve 
them along with the product data while using the trading center. 

Let us now scrutinize the arrangement of figure 6, ui which there is Ucensed an add- 
20 on product, whose manufacturer is different from the manufacturer of the base 
product. With Ucensing systems according to prior art commercial utiUzation of 
add-on products build on top of a base product, such as macro packages, is difficult 
from the viewpoint of both the manufacturer of the base product and the manufac- 
turer of the add-on product. In this embodiment the manufacturer of the add-on 
25 product can act as a dealer for both the base product and the add-on product. Thus it 
must be ensured, that the manufacturer of the base product will get the agreed 
shares of the license fees. Respectively this arrangement according to this embodi- 
ment can be used when an add-on product is offered for sale in a trading center, 
when there is appUed to the add-on-product similar Ucensing arrangements as to the 
30 base product. With this arrangement according to this embodiment both parties are 
able to control their own fees and product sales figures. 

In the embodiment represented in the figure 6 in the step 601 the manufacturer of 
the add-on product makes such a product, which wiU require acceptance from the 
producer of the base product For this purpose the manufacturer of the add-on prod- 
35 uct will order the tools necessary for production, a product code and Ucense tem- 
plates matching the different Ucensing conditions of the add-on product from the 
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^actuxer of tt,e base p^ot in fl>e step 602. The -^'^ZTIT^ 
product allocales to cote to to .tep 603 and deUv» die re^-ted data « 
^acta^r of the add^n product in me step 604. to the en*odnnent repre^^ 
to the figure 6. the add-on product is not distributed from a tra^ cea« of to 
n^nufacn^ of the base product, raflter man the n^nufacn^er of ^^^^I^; 
uct acts as a reseUer for to base product and for to add-on product Tie manu ac 
tuxers of to base product and add-on product wiU make an agreement on seUmg 
and tovoidng of to products m to step 605. 

Tte manufacturer of to base pnrfuct deUve. m to step 606 ^f™^^ 
trial Ucenses. and its Ucense templates as well as trial Ucenses o the ^-on p»du« 
,0 to manufacmrer of to add-on product. manufacturer of to ^^-P"'*"^ 
can combme various products and toil trial Ucenses. as pracucal. and 1="^^ 
product packages h> to customers to step to 607. When a customer decrd^ t» b^ 
I to step 608. he sends an order to to product distributor m to s^ 609, winch 
ilct^ a Uce^e request to to product and to to add^n product m totrrbutt^ 
which to this embodto>ent U to producer of to add-on product. s«tds to hcense 
requests and pre4eftaed cus«>mer toformation U> to producer of to base prodv.. 
iTto step 610. In addidon to manufacturer of to add-on product dehvers m the 
step 611 to portion of license fees defined to to agreement to to manuftctuier of 
Jbase product. For his part to manufacturer of to base product dehvers cus- 
u,met-specific execution Ucenses for both to base and to add-on product m to 
step 6inid to manufacmrer of to add-on product deUvers to execuaon Ucenses 
further to the customer in the step 613. 

Another advantageous embodiment of the invention relates to capacity constraints 
of a system. With the aid of capacity constraints it can be ensured, that a customer 
does not, without pennission, take to use more services or resources to use d.an he 
is entitled to. For example the number of users has to stay withm the hmrts of ^e h- 
cense conditions, and no ex^a concurrent users are allowed In addxhon w^ ^e 
aid of capacity constraints a fixed amomit of resources can be ensured to multiple 
, users wilout a single user consuming all the capacity. In addition, with the ard of 
capacity constraints we can prohibit the situation where a large numb^ of service 
Jueste will overload server resources causing system failure. Figure 7 represents 
Ta flow chart an embodiment, in which the usage of resources is controUed usmg 
two chosen constraints. THe constraints taken here as examples are the ^ount of 
5 service requests per time unit and the number of concurrent users. In addition or m- 
stead of these for example following data can be used in various constramts: user 
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identifier, product code, capacity of a service request, or classification of the re- 
source used. In addition, for example when inspecting service request per time unit 
there can be assigned to the service requests weighing coefficients defined using the 
service request an/or its variables. For example LAN and Internet users can have a 
5 different weighing coefficients. 

Figure 7 represents constraining capacity according to an advantageous embodiment 
of the invention. With the startup, in the block 701, inforaiation about constraints is 
read from the attributes of the license used. The constraints can also be defined to 
be fixed for example in the memory unit of the system or in connection with an ap- 

10 plication, when they are in the step 701 read from their location, rather than from li- 
cense's attributes. First it will be examined, are there set any capacity or time con- 
strainte 702. If constraints are found, in the step 703 there is created a table with an 
index column and a value column. The table can be located in the central memory 
of a server or a computer using the resource, from which the license control unit can 

15 use it. In the next phase 704 it is examined, are there are limitations for the number 
of users assigned for the hcense. If constraints were observed, another table will be 
created into the central memory in phase 705, which in this case has in addition to 
the index column and the value column, an identifier colunoui for user identification. 
Created tables are referred using index pointers referring to the index colunm. In the 

20 block 706 the tables are initialized with the indexes and limits read from the h- 
cense's attributes. 

In the block 707 there is received a service request, which contains user identifiers 
and possibly a capacity weight factor, which default value is one unit. The tables 
created in the blocks 703 and 705 are pointed with the aid of an index pointer point- 

25 ing to them. In the block 708 it is checked, that only the number of actions permit- 
ted by the capacity constraints is taken within a specific time period. The table can 
contain for example time-stamps, which are produced as one for each service re- 
quest. Originally the user purchases, for example^ a license for 12 service requests 
per minute (or altematively a more expensive hcense for 36 service requests per 

30 minute). From the time stamp of a new service request is subtracted the timestamp 
in 12 (or 36) index locations prior to this one - producing the time during which last 
12 (or 36) service requests have been executed. If the resulting time is. according to 
this example, more than 60 seconds, the control moves to the block 710. If the time 
difference calculated from tune stamps is less than the defined time limit i.e. an ex- 

35 tra service request is requested within 60 seconds, the control proceeds into the ex- 
ception handhng block 709. According to the instructions for exception handhng 
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me system caa. for example, wait for a c«.ain time, such a. 10 -"^"^ 
re-pLss the same service request agam orleave a service request un^ed ^ 
CTe over to process the next service request and/or to iBfcrm the mam user 

about the situation. 

If the r^mber of service requests per unit of time according to the capaci^ oon- 
12^.^ not exceeded, con^l moves to dteblock 710, where to ^e P^U not 
to Uble pointed by the index pointe. is set the cmren. ttme P"^"-^ J^^f^ 
circui. If the capacity load of the s^ice request is greater ^^- f^^^^ 
table position is filled with the same time-stamp. The capacity load of the service 
™Td2es the number of positions to be fflled The index pomter is moved to 
^rlf ^ position next to previously filled. If ti» table U full, me operation 
wiU proceed normally from the begimiing of the table. 

In the block 711 die table created in die block 705 is inspected. In the block 711 it 
In the DiocK / 1 1 me u. .„-. .,„ .k. „„r lahlp The user table contams 

wm be tested, whedier new users wiU fit mto the user ^ "Zn of the latest 
for each user identification one row. which contams the dme-stamp the W«t 
ZZ request of that user. Because ^s time stamp changes along with a new s^- 
"ce requ^t of die same user, the orde. of the rows of the table ma, cha^ of^r. 
Lause it typically is wanted to be maintamed in die order of die time-stamps due 
reXily In dl block 7 1 1 diere can be eidier changed the time-s^ of an ex- 
t^ Z I fl» table or added an user, if die number of die users m die «e . 
^er than die maximum number of users allowed, or a new user ^ aMeiJ 
the longest lasting user can be removal ftom die table, which '-P'^^J^^'^ 
.tamp ' older dian the session end delay defmed. After this, ~» J^^^ 
table will be updated in the bl»± 713, after which die syst«n - -^^ » 
new service r«,uest in the block 707. If a new user camiot be ^ «^ 
defined by die instructions for exception handling are executed m die 
w^coLponds to 40 exception handling proceeding executed m die b^k 7(«^ 
MTdns J contiol is moved to die block 708 to inspect capacity constx^ts In 
f:„Idim.nt presented here d«re are used tables as the d^ — 
, d« data. Instead of tables, odier, more advanced solutions can be med. such as dam 
rltines based on hnked records, in which d» used amomit o resources is re- 
corded cumulatively into die records instead of using rows of a table. 
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Claims 

1. A method for licensing digital resources and services, characterized in that ^ 
the method comprises the steps of: 

- as a response to a licensing request, transfomdng a license template into a license 
5 request by changing and/or adding (411) attribute values in a license request unit 

(103) handling license templates containing attributes, and transmitting (414) the 
formed license request to a Ucense creation unit (102) processing license requests, 

- in the license creation unit (102) transforming the license request into an execution 
license by changing and/or adding attribute values of the license request (506) and 

10 transmitting (512) the execution license to a Hcense control unit (104) controlling 
the use. of resources and/or services. 

2. A method according to claim 1, characterized in that it comprises steps of: 

- activating a certain license control unit (104) as a response to receiving an activat- 
ing service request directed to a resource or a service (205), 

15 - interpreting execution licenses of multiple services and/or resources in the certain 
license control unit (104), and 

- controlling in the certain hcense control unit (104) on the basis of the attribute 
values of the execution licenses the operation of licensed services and/or resources 
and activating service requests (206) directed to them. 

20 3. A method according to claim 1, characterized in that concurrent execution li- 
censes controlled by a certain license control unit (104) directed to a certain service 
and/or resource contain different number of attributes and/or different attribute val- 
ues and/or multiple values for certain attributes. 

4. A method according to claim 1, characterized in that it comprises a step of 
25 defining by the attribute values of an execution license at least a version number of 

a Ucense schema (311), a target environment of the execution license (321), an iden- . 
tifier of the licensed resource or service, and constraints of the execution license 
(322). 

5. A method according to claim 1, characterized in that it comprises steps of 
30 recognizing a set of pre-defined exceptional situations in the license control unit 
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10 



(104) and activating die instructions for exception handling (211) defined by the at- 
tribute values of the execution Ucense in each of the exceptional situaUons. 

6 A method as according to claim 5, characterized in that it comprises steps of 
observing, based on the version nmnber of a Ucense schema of a Ucense temp ate, m 
the Ucense request unit (103). situations, where there is no capabiUty m the Ucense 
control unit (104) to interpret attributes of an execution Ucense. and as a response to 
the observation, in the Ucense request unit (103), executing a pre-defined mstruction 
for exception handling. 

7 A method according to claim 1. characterized in that it comprises a step of 
dfifinmg m addition integrity constraints Umitmg interrelationships between attnb- 
utes for attribute values of an execution Ucense or a check-sum (330) descnbmg the 
integrity of attributes and/or a step of encrypting (312) part of a content of an execu- 
tion license. 

8. A method according to claim 1, characterized in that it comprises a step of 
15 combining, in the Ucense request unit (103), 

- data of a Ucense template containing attribute values defining the product and b^ 
ing interpretable by an Ucense control unit (104), and 

- certain values built-up from the target environment 

into a Ucense request (411), wMch is transmitted to the Ucense creation unit (414). 

9 A method according to claim 1, characterized in that it comprises steps of 
transforming, in the Ucense creation unit (102), a state-attribute fix>m a Ucense re- 
quest state to an execution Ucense state by changing attribute values (506), attachmg 
(509) to the defined execution Ucense certain Ucense templates and product descnp- 
tions which are usable by the Ucense request unit (103), and transmitting the execu- 
tion Ucense with the attachments to the Ucense control unit (104) of the target envi- 
ronnient. 

10 A method according to claim 1. characterized in that with the attributes of the 
execution Ucenses there is defined constraints for Umiting tiie use of a resource or a 



20 



25 



service. 



30 11 A method according to claim 1. characterized in that it comprises steps of 
transmitting the Ucense request through a data commmiication Unk to the Ucense 
creation unit (102). which is integrated to a certain electronic tradmg center, and 
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transmittiiig the execution license created in the license creation unit (102) through 
an electronic trading center to a customer. 

12. A method accordiiig to claim 1, characterized in that it comprises a step of 
transmitting customer-specific execution licenses (612, 613) as a response to a 

5 transmitted license request and customer data. 

13. A method according to claim 12, characterized in that the licensed services 
and/or resources, and their customer-specific execution licenses (612, 613) are con- 
trolled by two or more manufacturers and/or distributors. 

14. A method according to claim 1, characterized in that the steps as a response 
10 to a presented hcensing request are executed automatically, mechanically and the 

handled attributes and attribute values of each of the steps are at a range interpret- 
able by a license control unit (104). 

15. A system for licensing digital resources and services, characterized in that the 
system comprises 

15 - a license request unit (103) for transforming license templates into license requests 
by changing and/or adding attribute values contained in those, 

- a license creation unit (102) for transforming license requests into execution li- 
censes by changing and/or adding attribute values contained in those, and 

- a license control unit (104) for controlling the execution licenses based on attribute 
20 values contained in those. 

16. A system according to claim 15, characterized ia that an execution Ucense is 
a full license for making use of the whole resource or service; a limited license, a 
trial Ucense, an evaluation license, or a temporal Ucense for limiting the usage; a 
transfer Ucense for transferring an execution Ucense to another execution environ- 

25 ment; a continuation Ucense or an add-on product Ucense for extending the func- 
tionaUty. 

17. A system according to claim 15, characterized in that the system comprises in 
addition, a Ucense template unit (101) for creating Ucense templates based on a U- 
cense schema defining an attribute. 

30 18. A system according to claim 15, characterized in that the execution Ucense 
comprises a version number (311) of a Ucense schema and data about a product or a 
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service to be Ucensed, a Ucense type, a target environment (321). constraints of the 
execution license (322), and instructions for exception handhng (323). 

19 A system according to claim 15, characterized in that the Ucense request unit 
(103) comprises means for estabUshing a data communication comiection to the h- 
cense creation unit (102) for transmitting Ucense requests. 

20 A system according to claim 15. characterized in that the Ucense creation mnt 
(102) comprises means for recording a produced execution Ucense into a data struc- 
ture and/or for storing it in a mass memory. 

21 A system according to claim 15, characterized in that the Ucense creation unit 
10 (102) comprises means for estabUshing a data communication comiection for trans- 

mitting an execution Ucense to Ihe Ucense control umt (104). 

22 A system according to claim 15. characterized in that the Ucense creation mnt 
(102) comprises means for estabUshing a data communication comiection to a pay- 
ment system for paying flie Ucense fees. 

15 23. A system a«»rdix« to claim 15 or 22. cbaracteri«d in that the Uceme re- 
quest unit (103), the Uceuse cieatiou unit (102) ai»l the Ucense control unit (104) are 

located in the same equipment. 

24. A system according to claim 15, characterized in that the Ucense creation mut 
(102) is integrated to a payment system for paying die Ucense fees. 

20 25. A system according to claim 23 or 24. known from tiiat die used payment sys- 
tern is a chargeable service number. 

26 A system according to claim 15. characterized in tiiat tiie license contiol mnt 
(104) and die miit using the execution Ucense (105) are integrated into a umfoim, 
single unit. 

25 27 A system according to claim 15, characterized in tiiat die Ucense creation unit 
(102) is located in equipment of die party granting and managing die Ucenses. 

28 A system according to claim 15, characterized in tiiat a using miit (105) is a 
base product and used resources (106) are add-on products utiUzed by a base prod- 
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